home *** CD-ROM | disk | FTP | other *** search
/ Night Owl 9 / Night Owl CD-ROM (NOPV9) (Night Owl Publisher) (1993).ISO / 009a / mblib10.zip / RALCK003.DOC < prev    next >
Text File  |  1992-04-01  |  4KB  |  98 lines
  1. Name    : RALCK003.DOC
  2. Rev     : 003
  3. Date    : 29 Jan 1992
  4. Subject : RemoteAccess Message database locking for multiuser applications.
  5. Author  : Andrew Milner
  6.  
  7. This document (C) Copyright 1991,1992 by Andrew Milner. It may be freely
  8. distributed and/or included in other publications in it's entire and
  9. unmodified form only.
  10.  
  11.  
  12. PURPOSE
  13. -------
  14.  
  15. The purpose of this document is to describe the locking technique that is
  16. used by RemoteAccess 1.11 to ensure the integrity of it's message database
  17. in a multi-user environment. Developers of third party software that
  18. requires access to the database files are strongly encouraged to implement
  19. the described locking scheme.
  20.  
  21. The locking method is relatively simple; any competent developer should
  22. have no trouble implementing it. This document assumes that the reader knows
  23. how to call an interrupt with appropriate parameters, and read the values
  24. returned.
  25.  
  26.  
  27. LOCKING METHOD
  28. --------------
  29.  
  30. All message database files must be opened in DENYNONE mode.
  31.  
  32. 1. Use the INT 21 5Ch function to lock a region of the MSGINFO.BBS file;
  33.    This region starts at byte 407, and is 1 byte long. Locking a region
  34.    beyond the physical file size is considered valid by SHARE, and
  35.    ensures that other applications may access information contained in
  36.    the file for read purposes while it is locked.
  37.  
  38.    If an error occurred, the carry flag is set and the error returned
  39.    in AX:
  40.  
  41.         01h = Invalid function number, means SHARE is not installed.
  42.               How this is handled will vary - RemoteAccess disables
  43.               all locking and proceeds with the update.
  44.               (See note 5 below).
  45.  
  46.         06h = Invalid handle
  47.  
  48.         21h = Lock violation - this means that another application
  49.               is performing an update. Keep trying to get the lock
  50.               for 15 seconds, then abort the update with an error
  51.               message if unsuccessful.
  52.  
  53. 2. Perform the delete, add or modify operation.
  54.  
  55. 3. Unlock the region that was locked in step 1.
  56.  
  57.  
  58. NOTES
  59. -----
  60.  
  61. 1. The lock need only be applied for a delete, modify or add operation.
  62.    Simply reading the database does not require any special treatment.
  63.  
  64. 2. Terminating an application does NOT automatically remove this type of
  65.    lock. This means that if the application which created the lock terminates
  66.    abnormally before the lock is removed, no other application will be able
  67.    to update the message database. Only a reset will remove the lock.
  68.  
  69. 3. RemoteAccess 1.10 introduced an extension to the locking specification.
  70.    If unable to get a lock on the message database, RemoteAccess will
  71.    create (or touch the timestamp if it already exists) a zero-length
  72.    semaphore file called MBUNLOCK.NOW, in the message-base directory.
  73.    Applications which lock the message-base for longer than 15 seconds
  74.    continuously should check for the presence of this file, and if it has
  75.    been created or touched, release the lock temporarily to allow
  76.    RemoteAccess to perform an update operation.
  77.  
  78. 4. Applications should never assume that MSGINFO.BBS has not changed; this
  79.    file should be read after the lock (step 1) and rewritten again if
  80.    appropriate before the lock is removed (step 3).
  81.  
  82. 5. Many network shells also support the INT 21 5Ch function, making SHARE
  83.    unnecessary. Therefore, simply doing a SHARE "installation check" is
  84.    not sufficient. The application should attempt an actual lock in order
  85.    to determine whether this function is supported.
  86.  
  87.  
  88. CREDITS
  89. -------
  90.  
  91. The locking specification described in this document was originally
  92. co-developed by Andrew Milner and Joaquim Homrighausen. The MBUNLOCK.NOW
  93. extension (see note 3) was suggested by Gerard van der Land.
  94.  
  95.  
  96. --- End of "RALCK003.DOC" ---
  97.  
  98.